Had to build new binaries from of the HID bootloader to set the correct GPIO for BOOT1 to fix the boot into sketch issue, as it stood the source code was using a pin that would be floating.

Here's what I used for Black407Vet6 (/inc/main.h):

#define BOOT_1_PIN	GPIO_PIN_2 //Blackboard 407VET
#define BOOT_1_PORT	GPIOB
#define LED_1_PIN		GPIO_PIN_6
#define LED_1_PORT	GPIOA

And for Black407ZET6

#define BOOT_1_PIN	GPIO_PIN_2 //Blackboard 407ZET
#define BOOT_1_PORT	GPIOB
#define LED_1_PIN		GPIO_PIN_10
#define LED_1_PORT	GPIOF

ZET6 now tested and working.

Will test DIYMROE next.

You probably want to adjust the total available flash:

#ifdef HIDBL_F1
FLASH (rx)      : ORIGIN = 0x8000800, LENGTH = 64K
#else

might be:

#ifdef HIDBL_F1
FLASH (rx)      : ORIGIN = 0x8000800, LENGTH = 62K
#else

goes for all .ld scripts

@RickKimball yeah very good call, will update.

I've made the linker changes for all but BLACK407XX, the MAX size is passed in as a preprocessor variable - been at the gym so my brain is struggling to think how to knock 16KB off a preprocessed variable, or set it in boards.txt only for HID method?

Tips: you can define new switch and use it in ld script. Ex: LD_SIZE_OFFSET

Think I found a simpler way:

FLASH (rx) : ORIGIN = 0x8004000, LENGTH = LD_MAX_SIZE - 0x4000

Seems to work - ie doesn't throw linker error

I've left out the change to the upload method for now since 1) it works as is (no idea why) 2) it doesn't work when the correct naming is used.

I've attached precompiled bootloader bins, labelled with the boards they match.

firmwares.zip

What's the advantage of using this bootloader vs using the DFU versions?

Thanks in advance, E.

• not need to shuffle with jumpers
• can jump from user code to bootloader automatically
• no use of any drivers during upload

something more?

Pretty much that.

I'll upload a different formware for zet6 later, BOOT1 is pulled down on that board and it needs to be pulled up for this BL (so as an alternate it can be compiled to use PD4 which is an SDIO pin with a pullup... won't be active when the BL is running).

maybe just try to read K0 or K1

After seeing the above ref, I started to play with adding maple DFU support.

I can successfully upload to a maple mini with the original 0x5000 dfu bootloader - linking works well. BUT, CDC does not function - not sure why.

Will test against Bluepill & Blackpill

@BennehBoy on Maple do not forget the DISC pin PB9 handling. I will add the DISC pin management based on what is done in Roger's core.

@fpistm of course...

I had a quick look through the code but the LL stuff is beyond me at present...

Here's what STM32GENERIC does:

void USBDeviceClass::reenumerate() {
    /* Re-enumerate the USB */
      volatile unsigned int i;

    #ifdef USB_DISC_PIN
      pinMode(USB_DISC_PIN, OUTPUT);
      digitalWrite(USB_DISC_PIN, HIGH);
        for(i=0;i<512;i++);
      digitalWrite(USB_DISC_PIN, LOW);
    #else
      //pinMode(USBDP_PIN, OUTPUT);
      //digitalWrite(USBDP_PIN, LOW);
        //for(i=0;i<512;i++);
      //digitalWrite(USBDP_PIN, HIGH);


      pinMode(PA12, OUTPUT);
      digitalWrite(PA12, LOW);
      //HAL_Delay(1000);
      for(i=0;i<1512;i++){};
      pinMode(PA12, INPUT);
      //digitalWrite(PA12, HIGH);
      //HAL_Delay(1000);
      for(i=0;i<512;i++){};
    #endif
}

reenumerate gets called when CDC begins.

I tried 'frigging' it by issuing the same code in sketch startup, but CDC has already started at that point and things don'tr go well.

On a side note, Bluepill seems to get the BL 2.0 overwritten even though the linker & vector offset are 0x2000

OK, fixed bluepill...

So have working DFU BL 2.0 for BP 😃

Just need the DISC pin handling to get Maple Mini working

I still can't figure out why anything other than bmpMethod fails for the naming in boards.txt

I've pushed the DFU changes - Bluepill functional, Maple Mini semi functional but needs the USB_DISC_PIN change.

I think the DISC_PIN handling needs inserting here -> https://github.com/stm32duino/Arduino_Core_STM32/blob/master/cores/arduino/stm32/usb/usbd_conf.c#L58

I'm struggling a bit on the LL code to initialise and toggle the pin though.

Here's what I came up with, I used HAL... It works, but may not be the best way. This inserted just before the line indicated above.

It's hard coded for PB9 at present - but tbh I think there's only Maple Mini that uses this.

	/* BEGIN USER CODE */
	#ifdef USB_DISC_PIN
        uint16_t i=0;
	GPIO_InitTypeDef GPIO_InitStruct = {0};
	HAL_GPIO_WritePin(GPIOB, GPIO_PIN_9, GPIO_PIN_RESET);
	GPIO_InitStruct.Pin = GPIO_PIN_9;
	GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
	GPIO_InitStruct.Pull = GPIO_NOPULL;
	GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
	HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
	HAL_GPIO_WritePin(GPIOB, GPIO_PIN_9, GPIO_PIN_SET);
        for(i=0;i<512;i++);
        HAL_GPIO_WritePin(GPIOB, GPIO_PIN_9, GPIO_PIN_RESET);
        #endif
	
	/* END USER CODE */

Works a charm with #410

I will provide a PR tomorrow based on #410 with USB DISC PIN management and reenumerate

just in case, please add #undefine for HiGH and LOW before #endif

just in case, please add #undefine for HiGH and LOW before #endif

I removed those anyway - was a leftover from before conversion to HAL.

hi no worries, i think cubeprogrammer, DFU, HID can co-exist in a sense it is kind of a variant where the start of flash and vtab address is different that's all. in terms of tools, i'd think it's alright for ST to make a decision. users can always use 'external' tools like dfu-util or hid-flash to install the sketch say on the command line separately. or some instructions in a wiki can be placed to show how to add the tools. so non issues :)

Hi,

In case the user reaches this repository (usage instructions):
Serasidis/STM32_HID_Bootloader#11

@fpistm I noticed the 1.6.0 milestone, does this mean you're refactoring with stmcubeprogrammer?

@fpistm I noticed the 1.6.0 milestone, does this mean you're refactoring with stmcubeprogrammer?

I was wondering how long you would take to ask 😄
So, yes, I will review and test it after rebase/refactor it properly.

🤣

what about hid bootloader/programmer? it is not supported by stmcubeprogrammer.

I will add it

@BennehBoy, @Serasidis
I'm wondering if we should not keep only HID bootloader?
Is Maple DFU Bootloader 2.0 and Maple DFU Bootloader original (0x5000) really needed?
What is your thought about that?

Right, forgot this use case.
Thanks for the quick answer ;)

@BennehBoy

* F1 boards must use the latest 2K HID bootloader -> https://github.com/Serasidis/STM32_HID_Bootloader  (hid_flash tool will warn if an older version is installed)

I'm little bit lost with that. I know some users works on this but I think it was not the case here as it is not compatible with EEPROM emulation.
And reffering to your updated ld the BL is a the start of the flash.

Can you explain further?

When I was creating the PR the HID BL author updated his repo so that the tools would refuse to flash devices with an earlier version of the BL installed....

Then some more commits were made to move the F1 version of the BL to the end of flash, these were then backed out.

I've noticed some recent commits but have not had my eye close enough on it to see if the end of flash has been re-introduced (I doubt it would be due to some other issues).

Ok so your limitation on your OP is not correct.
Currently, the bootloader is flashed at the beginning?

The limitation is correct with the hid tool that I supplied in the tools repo. Where the loader is flashed in flash memory is irrelevant, the tool still requires v 2+ to be on the device.

Oh ok. Sorry, i've read that it was flash on the latest sector 🤣
So, I've clen up your PR (split commit, clean code, enhance boards.txt, add switch to enable it only for compatible series, use backup API, ...)
See #525

Out of curiosity, could one of you please explain what is currently hindering this PR from being merged in relatively lay-person parlance? From what this looks to be, It would be of great use to me to have this feature in the STM32duino core.

Out of curiosity, could one of you please explain what is currently hindering this PR from being merged in relatively lay-person parlance? From what this looks to be, It would be of great use to me to have this feature in the STM32duino core.

@neilbalch
This PR is now superseded by #525
This will be merged soon.
@BennehBoy made a great job on this PR. It only required some time to review, test and merge.

@fpistm I figure you've guessed my time has been limited lately - the original reason I got involved with microcontrollers, my car, has stolen most of my recent time... Engine rebuilds, gearbox work etc. Never buy a Land Rover!

I'll try and get some testing of PR #525 done soon.